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ABSTRACT 

This  paper  argues  that  the  existing  model-driven  architec¬ 
ture  paradigm  does  not  adequately  cover  the  visual  model¬ 
ing  of  security  protocols:  sequences  of  interactions  between 
principals.  A  security  protocol  modeling  formalism  should 
be  not  only  well-defined  but  also  support  event-based,  com¬ 
positional,  comprehensive,  laconic,  lucid,  sound,  and  com¬ 
plete  modeling.  Candidate  visual  approaches  from  both  the 
OMG’s  MDA  and  other  more  well-defined  formalisms  fail 
to  satisfy  one  or  more  of  these  criteria.  By  means  of  two 
example  security  protocol  models,  we  present  the  GSPML 
visual  formalism  as  a  solution. 
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1.  INTRODUCTION 

The  model- driven- approach  ]38]  to  software  construction 
promises  to  improve  software  quality  and  reduce  costs  through 
automatic  construction  of  software  from  (visual)  models.  Vi¬ 
sual  modeling  is  slowly  becoming  a  common  practice  for 
software  developers,  so  the  hope  is  that  practitioners  will  be 
comfortable  with  using  visual  models  to  design  their  soft¬ 
ware.  (In  this  paper,  we  use  the  unqualified  term  modeling 
to  mean  visual  modeling.) 

The  force  of  common  practice  is  defining  the  model-driven- 
approach  in  terms  of  the  Object  Management  Group’s  Model 
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Driven  Architecture  or  MDA.  The  core  of  the  MDA  is  UML 
2.0  [32].  Neither  UML  2.0  (henceforth  UML)  or  MDA  treats 
security  as  much  more  than  a  service;  there  are  no  models 
for  security  per  se. 

This  raises  the  question  of  what  security-specific  aspects  of 
software  development,  if  any,  need  coverage  in  this  paradigm. 
This  paper  argues  that  there  are  security-specific  issues  that 
cannot  be  modeled  well  with  existing  features  of  MDA.  These 
issues  need  adequate  coverage  in  model-driven  approaches. 

One  of  the  most  significant  security-specific  aspects  of 
software  development  not  covered  by  the  MDA  is  the  secu¬ 
rity  protocol.  Security  protocols  are  sequences  of  allowable 
interactions  between  principals.  A  principal  is  an  entity  that 
participates  in  a  security  system.  Security  protocols  are  not 
necessarily  about  cryptography;  one  of  our  examples  will 
model  a  security  protocol  that  involves  no  cryptography  at 
all. 

The  UML  candidates  for  visual  modeling  of  security  pro¬ 
tocols  all  have  shortcomings.  Existing  alternatives  outside  of 
UML  also  have  similar  problems,  for  various  reasons.  Some 
of  these  difficulties  are  visual  modeling  issues  and  others  are 
semantic  issues.  One  of  the  most  critical  semantic  require¬ 
ments  for  modeling  security  protocols  is  the  ability  to  define 
all  traces  of  a  protocol  with  a  single  model  as  opposed  to 
being  able  to  describe  any  trace  with  a  single  model.  Ex¬ 
plicit  definition  of  all  traces  is  necessary  because  each  bad 
trace  has  the  potential  to  become  a  security  flaw.  A  highly 
desirable  visual  modeling  feature  is  event-based  modeling, 
as  opposed  to  state-based  modeling.  The  distinction  is  that 
state-based  modeling  is  best  for  designing  reactive  behavior 
while  event-based  modeling  is  best  for  designing  interactive 
behavior.  State-based  modeling  requires  us  to  work  with  in¬ 
ternal  computational  aspects,  such  as  states  or  triggers,  to 
construct  the  traces  of  a  protocol.  An  event-based  modeling 
paradigm  lets  us  work  directly  with  the  external  events  and 
traces  of  a  protocol. 

2.  MOTIVATION 

The  core  purpose  of  visual  modeling,  as  opposed  to  other 
forms  of  modeling,  is  presentation  and  understanding.  For¬ 
mal  verification,  machine-generated  implementation,  and  other 
automatic  processing  are  probably  done  better  with  text- 
based  models.  In  fact,  a  good  well-defined  visual  language 
will  always  be  a  form  of  syntactic  sugar  ]24]  for  some  text- 
based  languge,  since  the  text-based  semantics  will  be  needed 
for  execution.  So  our  interest  is  in  security  protocol  mod¬ 
eling  that  has  good  visual  properties  for  presentation  and 
human  understanding,  without  sacrificing  soundness  that 
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supports  translation  into  text-based  models.  This  leads  to 
the  following  criteria  for  security  protocol  modeling: 

•  The  visual  formalism  should  have  a  well-defined  syntax 
and  semantics. 

•  The  visual  formalism  should  be  event-based.  It  should 
focus  on  interaction  patterns  between  principals  and 
abstract  away  from  details  of  internal  computations. 
The  importance  of  this  is  underscored  by  the  fact  that 
existing  security  protocol  modeling  tools  use  event- 
based  visual  models,  rather  than  state-based  models. 


process  region 

event  region 

Figure  1:  Basic  Boxes  of  GSPML 

3.  GSPML 


•  The  visual  formalism  should  support  models  that  are 
eompositional.  Compositional  models  are  constructed 
from  sub-models  that  identifiably  correspond  to  the 
principals  of  the  protocol. 

•  The  visual  formalism  should  suport  models  that  are 
eomprehensive.  It  should  be  capable  of  defining  all 
traces  of  a  protocol  by  means  of  a  single  diagram. 

•  The  visual  formalism  should  suport  models  that  are  la- 
eonic  [15] .  A  non-laconic  model  is  one  where  some  ob¬ 
ject  or  relation  in  the  represented  abstraction  is  mod¬ 
eled  more  than  once.  Following  Guizzardi  [14],  a  model 
M  is  laconic  w.r.t.  an  abstraction  A  if  the  interpreta¬ 
tion  mapping  from  A4  to  .A  is  injective. 

•  The  visual  formalism  should  suport  models  that  are 
lucid  [15].  A  non-lucid  model  is  one  where  some  ob¬ 
ject  or  relation  in  the  model  represents  more  than  one 
object  or  relation  from  the  modeled  abstraction.  Fol¬ 
lowing  Guizzardi  [14],  a  model  Ai  is  laconic  w.r.t.  an 
abstraction  A  if  the  representation  mapping  from  A  to 
Ai  is  injective. 

•  The  visual  formalism  should  suport  models  that  are 
sound  [15].  An  unsound  model  is  one  where  some 
model  object  or  relation  has  no  corresponding  object 
or  relation  in  the  represented  abstraction.  Following 
Guizzardi  [14],  a  model  A4  is  sound  w.r.t.  an  abstrac¬ 
tion  A  if  the  representation  mapping  from  ^  to  A4  is 
surjective. 

•  The  visual  formalism  should  suport  models  that  are 
complete  [15].  An  incomplete  model  is  one  where  some 
object  or  relation  in  the  represented  abstraction  has 
no  corresponding  model  object  or  relation.  Following 
Guizzardi  [14],  a  model  A4  is  complete  w.r.t.  an  ab¬ 
straction  A  if  the  interpretation  mapping  from  A4  to 
A  is  surjective. 

The  UML  candidates  for  visual  modeling  are  either  not 
well-defined  or  they  fail  to  suport  comprehensive  or  laconic 
models.  Visual  modeling  candidates  outside  UML  are  well- 
defined  but  are  either  state-based  or  fail  to  suport  models 
that  are  laconic  or  comprehensive.  The  visual  interfaces  to 
current  security  protocol  modeling  tools  also  do  not  provide 
a  formalism  that  satisifies  all  of  our  criteria.  These  candi¬ 
dates  are  not  necessarily  bad  but  are  not  suited  to  visual 
security  protocol  modeling,  according  to  one  or  more  of  the 
criteria  above.  We  make  these  statements  without  explana¬ 
tion  here  but  present  a  detailed  justification  in  Section  4. 


We  present  GSPML  as  a  visual  security  protocol  modeling 
language  that  satisfies  all  of  the  above  criteria.  (At  the 
time  this  paper  was  written,  GSPML  did  not  stand  as  an 
acronym  of  any  particular  name.)  The  goal  of  the  GSPML 
alternative  is  to  provide  a  visual  modeling  language  suitable 
for  the  security-specific  problem  of  protocol  modeling.  The 
emphasis  is  on  a  solid  visual  model  with  complete  syntax 
and  semantics,  rather  than  tool  application  via  the  specific 
semantics.  Given  a  well-defined  visual  modeling  language,  a 
variety  of  formal  techniques  could  be  used,  including  many 
with  semantics  that  differ  from  the  semantics  of  GSPML 
(e.g.  NPATRL,  GAPSL,  strand  spaces  [12,  39[,  or  a  general 
LTS). 

The  GSPML  alternative  is  well-defined,  event-based,  com¬ 
positional,  comprehensive,  and  laconic.  This  is  demonstrated 
by  the  diagram  at  the  end  of  this  paper  (see  Figure  11)  that 
defines  a  complete  model  of  the  Yahahlom  cryptographic  se¬ 
curity  protocol  [5].  This  diagram  fits  on  a  single  page  but 
defines  all  possible  traces  of  the  protocol  interacting  with  a 
Dolev-Yao  intruder.  So  a  single  GSPML  diagram  can  define 
not  only  all  the  correct  behavior  of  a  protocol  but  also  its 
behavior  under  many  attacks. 

Our  presentation  here  in  Section  3  does  not  define  a  se¬ 
mantics  for  the  language  but  provides  an  introduction  and 
demonstrates  the  applicability  of  GSPML.  The  meaning  of 
well-formed  GSPML  diagrams  is  compatible  with  several 
forms  of  process  algebra  but  it  is  not  necessary  to  under¬ 
stand  process  algebra  in  order  to  understand  the  GSPML 
presented  in  this  paper.  It  is  necessary  to  understand  that 
GSPML  models  are  arrangements  of  nested  rectangles  or 
boxes  that  define  trace  generating  processes. 

In  GSPML,  every  trace-generating  process  is  defined  by  ei¬ 
ther  a  process  box  or  a  process  box  name.  (For  the  rest  of  this 
paper  we  will  use  the  term  process  and  box  interchangeably.) 
There  are  two  major  distinctions  between  boxes:  sequential 
boxes  and  concurrent  boxes,  as  in  Figure  1.  A  sequential  box 
has  rectangular  corners  and  models  sequential  processes.  A 
concurrent  box  has  round  corners  and  models  concurrent 
processes.  A  process  box  name  (or  more  simply,  box  name) 
may  only  appear  as  a  label  for  a  box,  or  inside  a  process 
region  of  a  box.  A  process  region  may  have  only  one  box 
or  box  name  in  it.  Sequential  boxes  also  have  event  regions 
that  contain  the  events  of  a  GSPML  model.  When  all  of  the 
events  in  the  event  region  of  a  sequential  box  have  occurred 
then  the  sequential  box  is  replaced  by  or  becomes  the  box 
contained  or  named  in  the  process  region  below  the  event 
region.  So  GSPML  diagrams  are  read  from  top  to  bottom 
and  outside  to  in. 

We  present  the  details  of  GSPML  by  examples  of  its  use. 
We  give  two  examples:  first  a  cryptographic  security  proto¬ 
col  and  then  a  non-cryptographic  security  protocol. 


Figure  2:  A  GSPML  Model  of  One  Run  of  the  Ya- 
halom  Protocol 


3.1  The  Yahalom  Protocol 

Our  example  of  a  cryptographic  security  protocol  is  the 
Yahalom  protocol.  The  GSPML  model  is  based  on  the  CSP 
process  algebra  model  presented  by  Ryan,  Schneider,  et  al. 
[35].  Readers  interested  in  process  algebra  modeling  of  se¬ 
curity  protocols,  as  opposed  to  exposition  of  the  GSPML 
language,  should  consult  their  work. 

The  Yahalom  protocol  is  used  to  establish  a  session  key 
kab  between  two  principals  A  and  B,  via  a  server  J.  Fig¬ 
ure  2  shows  a  simple  GSPML  diagram  of  a  single  run  of  the 
protocol,  where  principal  A  initiates  a  session  with  principal 
B.  The  protocol  run  is  simplified  in  the  sense  that  the  prin¬ 
cipals  are  assumed  to  be  somehow  prepared  to  synchronize 
on  each  other’s  nonces  and  the  session  key,  in  advance  of 
the  protocol  run.  That  is,  each  event  contains  precisely  the 
nonces  Ha,  rib  and  session  key  kab  to  make  this  run  work. 
None  of  the  three  named  boxes  in  Figure  2  is  defined  as  be¬ 
ing  prepared  to  deal  with  any  possible  well-formed  nonce  or 
session  key. 

The  goal  of  Figure  2  is  to  introduce  the  protocol,  not 
model  it.  That  is,  the  GSPML  of  Figure  2  is  playing  the  role 
of  the  usual  message  sequence  diagram  used  to  introduce  a 
cryptographic  protocol.  So  Figure  2  shows  that  GSPML 
can  be  used  for  explanation  as  well  as  definition  of  security 
protocols. 

Figure  2  provides  a  good  non-trivial  first  example  of  GSPML. 
The  two  outermost  (unnamed,  round-cornered)  boxes  are 
concurrent  boxes  that  model  the  concurrent  interaction  of 
the  principals  A  and  B  and  the  server.  Each  concurrent  box 
has  two  process  regions.  The  outermost  concurrent  box  has 
the  next  inner  concurrent  box  in  one  of  its  process  regions 
and  a  sequential  box  named  J  in  its  other  process  region. 
The  sequential  box  J  contains  the  events  that  model  the 
protocol  steps  of  the  server  in  a  single  run  of  the  Yahalom 


protocol.  The  second  concurrent  box  contains  the  sequential 
boxes  named  A  and  B  defining  the  corresponding  protocol 
steps  for  the  initiator  and  responder. 

Each  event  in  a  sequential  box  is  denoted  by  a  small  circle, 
called  an  event  symbol,  on  the  left  boundary  of  the  box’s 
event  region.  The  top-to-bottom  order  of  the  event  symbols 
defines  the  sequential  order  of  the  events  for  that  box.  So 
the  events  of  sequential  box  A  at  the  top  of  Figure  2  are 

a.b.a.Ua 

j.a.{b.kab-na-nb} 

ServerKey(b) 

a.b.m.{nb}kab 

Sequential  boxes  communicate  or  share  their  events  via  in¬ 
terface  port  symbols  on  enclosing  concurrent  boxes.  Goncur- 
rent  boxes  with  interface  port  symbols  are  parallel  boxes  that 
define  communication  between  their  components.  An  inter¬ 
face  port  symbol  is  a  small  rectangle  placed  on  the  boundary 
between  the  process  regions  of  a  parallel  box. 

Shared  events  are  connect  by  synchronization  lines.  The 
synchronization  lines  shown  in  Figure  2  are  an  example  of 
concrete  synchronization  lines  because  they  connect  event 
symbols  directly.  (There  are  abstract  synchronization  lines 
that  do  not  connect  event  symbols.  They  will  be  presented 
shortly.) 

Concrete  synchronization  lines  depict  sharing  of  the  spe¬ 
cific  events  they  connect.  The  events  connected  by  the  syn¬ 
chronization  lines  happen  at  the  same  time;  they  appear 
as  a  single  event  to  an  outside  observer.  Synchronization 
lines  may  be  drawn  anywhere  that  provides  clarity  while 
connecting  the  events,  but  must  pass  through  the  interface 
port  symbol  that  defines  the  parallel  combination. 

In  Figure  2  the  shared  events  model  the  transmission  and 
receipt  of  a  message  in  the  security  protocol. 

Events  in  GSPML  may  have  compound  names.  The  event 
itself  is  atomic  but  various  information  about  the  event  can 
be  represented  using  a  “dot”  separator,  as  in  x.y  between 
the  name  components  x  and  y. 

In  Figure  2’s  model  of  a  run  of  the  Yahalom  protocol,  the 
events  have  compound  names  with  the  first  component  indi¬ 
cating  the  sender  for  that  event  and  the  second  component 
indicating  the  receiver  of  the  event.  For  example,  the  first 
event  of  box  A  is  the  compound  event  a.b.a.Ua'.  a  trans¬ 
mission  from  source  a  to  destination  b  of  the  message  a.Ua. 
The  concrete  synchronization  line  from  event  a.b.a.Ua  in  box 
A  to  the  same  event  in  box  B  models  the  transmission  of 
message  a.Ua  by  principal  A  and  receipt  by  principal  B. 

Figure  2  also  contains  concrete  synchronization  lines  con¬ 
necting  events  with  different  names  at  source  and  destina¬ 
tion.  For  example  the  second  event  of  box  A  is  named 
j.afb.kab.Ua.Ub} servarKay(a)-m  while  the  sourcB  eveut  in  box 
J  is  named  j.a{h.kab.na.nb}sarvarKay{a)-{°‘-kab}s  erverKey^^jy-^  • 
This  aliasing  indicates  that  the  source  and  destination  boxes 
have  different  interpretations  of  the  shared  event.  In  this 
case,  the  initiator  (modeled  by  box  A)  cannot  read  the 
last  component  {a.kab} SarvarKey^y.^  because  it  does  not  have 
ServerKeyih)  so  it  interprets  that  component  as  simply  as 
a  sequence  of  bits  m. 

We  can  tell  which  event  happens  first  in  the  diagram  of 
Figure  2  by  noticing  that  second  event  of  the  B  box  happens 
at  the  same  time  as  the  first  event  of  the  J  box,  so  box  J’s 
first  event  cannot  start  the  protocol.  As  the  diagram  shows 
it,  the  first  event  in  the  protocol  must  be  the  shared  first 
event  of  boxes  A  and  B:  transmission  of  the  message  a.Ua 


from  a  to  h.  (It  is  not  always  necessary  that  a  unique  event 
in  a  GSPML  diagram  be  the  hrst  event;  the  first  event  can 
be  one  of  several  possibilities.) 

The  Yahalom  protocol  works  as  follows:  principal  A  wishes 
to  establish  a  session  with  principal  B  and  initiates  a  run  of 
the  protocol  by  sending  its  identity  a  and  a  nonce  Ua  to  prin¬ 
cipal  B.  This  is  shown  by  the  synchronization  of  the  hrst 
event  a.b.Ua  communicated  from  the  A  box  to  the  B  box  in 
Figure  2.  Box  B  then  sends  a,na  and  its  own  nonce  nb,  en¬ 
crypted  under  the  key  ServerKeyib)  to  the  server.  This  is 
show  in  Figure  2  by  the  synchronization  of  the  second  event 
of  the  B  box  with  the  hrst  event  of  the  J  box.  The  third 
step  of  the  protocol  has  the  server  (box  J)  send  principal 
B’s  identity  h,  both  nonces  na,nb,  a  session  key  kab,  and  a 
message  {a.kab} ServerKey(b)  to  principal  A.  This  is  shown  in 
Figure  2  by  the  synchronization  of  the  second  event  of  the  J 
box  with  the  second  event  of  the  A  box,  where  the  initiator 
sees  the  message  {a.kab} ServerKey(b)  simply  as  a  bit  string 
m. 

In  Figure  2  the  end  of  the  protocol  run  is  shown  by  the 
J  box  becoming  the  (constant)  process  box  SKIP  that  de¬ 
notes  successful  termination,  while  the  A  and  B  boxes  be¬ 
come  parameterized  Session  boxes  that  denote  the  start  of 
a  session  between  principals  A  and  B. 

3.2  A  Complete  GSPML  Model 

Defining  a  complete  model  of  the  Yahalom  protocol  will 
explain  more  of  the  GSPML  language  and  demonstrate  that 
it  is  event-based,  comprehensive,  concise,  well-defined,  and 
composable.  Our  complete  model  follows  the  Dolev-Yao 
structure  where  the  intruder  acts  as  the  network  connect¬ 
ing  the  principals.  The  complete  GSPML  model  is  shown 
as  Figure  11  at  the  end  of  the  paper,  but  we  do  not  use 
that  figure  to  explain  GSPML.  Instead,  the  model  is  pre¬ 
sented  beginning  from  a  top-level  view.  Then  components 
of  the  complete  model  are  explained,  proceeding  from  sim¬ 
pler  constructions  to  more  complex.  This  will  demonstrate 
the  abstraction  capabilities  of  GSPML.  The  form  of  our  ex¬ 
planation  is  to  introduce  different  language  elements  by  ex¬ 
ample.  The  meaning  of  each  language  element  is  explained 
first  and  then  the  protocol  modeling  structure  is  explained 
based  on  the  meaning. 

3.3  High-Level  Model  Structure 

Figure  3  shows  a  top-level  view  of  the  model  of  Figure 
11,  with  principals  A  and  B  as  abstract  concurrent  boxes 
User  (a)  and  User(b),  the  server  as  the  abstract  concurrent 
box  Server  (j),  and  the  intruder  as  abstract  sequential  box 
Intruder(X).  Abstract  boxes  have  no  internal  regions  for 
events  or  processes.  This  use  of  abstract  concurrent  and 
sequential  boxes  shows  the  high-level  structure  of  the  model 
without  the  internal  details. 

The  basic  structure  of  Figure  3  is  a  parallel  box  synchro¬ 
nizing  the  sequential  Intruder{X)  box  with  the  nested  in¬ 
terleaving  boxes  that  model  User{a),  User{b)  and  Server{j). 
The  boxes  modeling  Intruder{X),  User(a),  User(b)  and 
Server[j)  are  each  enclosed  by  a  box  drawn  with  dashed 
lines,  just  like  a  synchronization  line.  These  dashed  boxes 
indicate  the  use  of  renaming  to  map  the  names  of  events  into 
other  event  names  that  correspond  to  the  events  of  another 
box.  This  lets  us  give  events  names  that  are  meaningful 
to  the  box  that  contains  them,  on  either  end  of  a  synchro¬ 
nization.  A  good  example  of  this  is  shown  in  Figure  11  at 


the  end  of  this  paper,  which  uses  renaming  to  map  the  send 
and  receive  components  of  events  to  their  proper  roles  in  the 
protocol.  That  is,  a  send  is  hrst  mapped  to  a  take  which 
connects  it  through  the  interface  port  of  Figure  11;  then  the 
take  is  mapped  to  a  learn  by  the  intruder.  Figure  4  shows 
that  the  intruder’s  events  begin  with  either  learn  or  say  and 
thus  should  be  renamed  to  connect  them  to  the  send  and 
receive  of  the  protocol. 

The  boxes  contained  in  the  process  regions  of  the  inter¬ 
leaving  boxes  are  interleaved,  since  there  is  no  interface  port 
symbol  on  the  boundary  between  them.  The  events  of  the 
boxes  contained  in  the  two  process  regions  of  an  interleav¬ 
ing  box  are  not  synchronized.  For  example,  if  the  boxes 
U ser{b)  and  User(a)  each  contained  an  event  named  a  and 
both  boxes  performed  an  a  event,  then  the  traces  of  the 
interleaving  concurrent  box  containing  them  would  include 
two  a  events,  not  one.  Even  though  the  synchronization 
lines  connect  to  the  interior  of  both  User{a)  and  User{b), 
we  can  tell  that  they  do  not  communicate  directly  because 
the  synchronization  lines  do  not  go  through  an  interface  port 
symbol  on  the  region  boundary  between  them. 

Figure  3  shows  that  none  of  the  boxes  U ser{a),U ser{b), 
or  Server(j)  communicates  directly  but  that  the  three  inter¬ 
leaved  boxes  are  connected,  via  the  outer  parallel  box,  with 
the  intruder  box  Intruder(X).  The  synchronization  lines  con¬ 
necting  the  boxes  are  abstraet  synchronization  lines  because 
they  do  not  connect  to  specific  events  but  are  terminated  in¬ 
side  the  process  region  of  the  applicable  box,  without  touch¬ 
ing  anything.  This  termination  of  an  abstract  synch  line  in¬ 
dicates  that  the  shared  event  is  within  some  greater  level  of 
detail  inside  the  applicable  box.  These  abstract  synchroniza¬ 
tion  lines  are  similar  to  the  abstraction  technique  presented 
by  Henderson,  et  al.  [18]  but  with  a  different  semantics.  Ab¬ 
stract  synchronization  lines  in  a  GSPML  diagram,  used  as 
shown  in  Figure  3  have  no  meaning  but  provide  a  reminder 
of  the  communication  pattern  in  the  more  concrete  models. 

In  a  software  tool  these  abstract  synchronization  lines  would 
be  place  holders  for  the  concrete  synchronization  lines  of  a 
more  detailed  view.  In  Figure  3  the  abstract  synchroniza¬ 
tion  lines  suggest  that  box  Intruder (X)  participates  in  every 
communication  event,  from  any  of  the  principals. 

3.4  Intruder  Structure 

Figure  4  shows  the  complete  structure  of  the  intruder  box 
Intruder(X).  Figure  4  is  an  example  of  an  external  ehoice  box 
indicated  by  a  square  external  choiee  symbol  on  the  left  end 
of  the  boundary  between  its  process  regions.  An  external 
choice  box  offers  a  choice  of  either  of  its  two  boxes  to  its 
environment.  The  first  event  of  the  combination  determines 
the  choice  of  box. 

In  Figure  4  the  events  are  named  m  because  the  intruder 
may  or  may  not  be  able  to  interpret  the  components  of  an 
event  name.  In  Figure  4  this  notation  shows  that  the  in¬ 
truder  box  Intruder{X)  can  copy  and  store  details  about 
any  event  communicated  between  the  principals.  This  is 
shown  by  the  parameterized  box  name  Intruder{KnownFactsU 
{m}).  The  set  KnownFacts  models  not  only  the  events 
seen  by  Intruder{X)  but  also  any  event  components  that 
Intruder{X)  may  be  able  to  separate  and  combine  with 
components  from  other  events.  The  set  KnownFacts  also 
includes  any  event  components  that  Intruder{X)  may  be 
able  to  encrypt  or  decrypt,  according  to  keys  it  already 
knows  or  learns  from  seeing  protocol  events. 
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Figure  3:  Yahalom:  The  Top-Level  Structure 
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Figure  4:  Yahalom:  The  Intruder 


The  use  of  external  choice  indicates  that  the  intruder 
is  prepared  to  participate  in  any  events  that  any  of  the 
three  other  principals  offers.  It  can  either  “copy”  them 
into  KnownFacts  and  pass  them  along,  receive  transmitted 
events  but  not  relay  them,  or  spontaneously  generate  bogus 
events  that  are  based  on  the  elements  of  KnownFacts. 

Because  the  intruder’s  events  are  in  distinct  sequential 
processes,  the  intruder  box  does  not  have  to  make  its  traces 
of  send  events  correspond  to  the  traces  of  receive  events  it 
saw.  The  box  following  a  receive  event  (incoming  arrow) 
has  the  parameter  c\ose{KnownFacts  U  {m})  that  models 
the  intruder  accumulating  facts  in  KnownFacts.  The  close 
function  models  the  parsing,  decrypting,  encrypting  and  re¬ 
composing  of  events  seen  by  the  intruder.  Definition  of  the 
close  function  is  outside  the  scope  of  the  GSPML  language, 
but  is  represented  by  the  parameterized  box  name.  Use  of 
the  parameter  means  that  there  is  a  distinct  intruder  box 
for  each  possible  value  of  the  parameter. 

The  other  part  of  the  intruder  box  uses  KnownFacts  Pi 
Messages  to  model  faithful  transmission  as  well  as  malicious 
replay  and  the  substitution  of  well-formed  but  spurious  mes¬ 
sages  by  the  intruder. 

The  meaning  of  the  intruder’s  GSPML  structure  is  that 
box  Intruder(X)  must  receive  any  event  “sent”  by  any  prin¬ 
cipal  but  it  is  not  required  to  relay  that  event  and  may  per¬ 
form  arbitrarily  many  send  events  before  receiving  an  event 
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Figure  5:  Yahalom:  The  Server  Process  Server(j) 


from  a  principal. 

The  sequential  intruder  box  Intruder{X)  of  Figure  4  is 
able  to  handle  many  events  from  many  protocol  runs  be¬ 
cause  it  is  recursive.  The  box  participates  in  one  event  of 
one  protocol  run,  by  its  choice  mechanism.  After  the  single 
protocol  event,  it  uses  recursion  to  become  another  box  that 
is  prepared  to  make  all  of  the  same  choices  again.  Recur¬ 
sion  is  defined  by  box  names,  rather  than  graphical  notation. 
That  is,  the  intruder  box  is  recursive  because  its  box  name 
Intruder{X)  appears  within  the  process  regions  of  a  box 
named  Intruder (X).  (In  our  prototyping  to  date,  we  have 
found  that  purely  visual  modeling  of  general  recursion  is 
problematic.)  A  convention  for  GSPML  uses  a  bold  font  for 
box  names  as  a  reminder  that  those  boxes  are  intended  to  be 
recursive.  In  Figure  4  the  bold  font  box  name  Intruder(A) 
indicates  the  intended  recursion,  but  GSPML  attaches  no 
meaning  to  the  font  used  for  the  box  names. 

3.5  Server  Structure 

The  next  figure.  Figure  5,  shows  the  full  definition  of  the 
server  box  Server (j).  This  box  demonstrates  several  features 
of  GSPML  that  we  have  not  seen  yet,  including  two  general¬ 
ized  or  indexed  boxes.  The  outer  concurrent  box  is  a  indexed 
interleaving  box.  It  is  a  concurrent  interleaving  box  because 
it  has  no  interface  port  on  the  boundary  between  its  process 
regions.  The  double  line  separating  the  two  process  regions 
tells  us  that  it  is  an  indexed  interleaving  box.  The  upper 
process  region  of  an  indexed  interleaving  box  has  a  specifica¬ 
tion  for  the  index  set  and  the  lower  process  region  contains 
a  parameterized  box  describing  the  processes  that  are  in¬ 
terleaved.  The  meaning  of  the  box  Server{j)  is  that  for 
each  possible  key  k^b  G  KeysServer,  there  is  an  unnamed 
interleaved  box.  The  index  parameter  kab  distinguishes  the 
structural  difference  between  each  interleaved  box. 

In  Figure  5,  the  each  interleaved  box  is  itself  an  indexed 
box,  an  indexed  external  choice  box.  An  indexed  exter¬ 
nal  choice  box  allows  its  environment  to  choose  from  an 
indexed  set  of  boxes.  An  indexed  external  choice  box  is 
depicted  by  the  double  square  external  choice  symbol  in 
its  upper  left  corner.  The  index  set  is  the  double  index 
a,b  G  U  sers;  na,nb  G  Nonce.  This  double  index  shows  that 
this  indexed  external  choice  box  offers  a  choice  of  boxes  over 
all  possible  pairs  of  users  and  pairs  of  possible  nonces.  The 
first  event  of  each  box  chooses  one  sequential  box  that  then 
performs  the  appropriate  protocol  run.  This  innermost  se¬ 
quential  box  of  Figure  5  is  essentially  the  same  as  the  server 
box  shown  in  Figure  2.  It  gives  the  order  of  the  protocol 
steps  followed  by  the  server  in  a  single  run,  with  all  values 
fixed.  The  box  containing  this  single  server  run  uses  exter- 


Figure  6:  Yahalom:  High-Level  Structure  of  Both 
Users 

nal  choice,  indexed  over  all  possible  pairs  of  agents  and  all 
possible  pairs  of  nonces,  to  define  a  collection  of  server  boxes 
that  can  conduct  a  single  run  for  a  fixed  key  kah,  with  any 
pair  of  users  applying  any  pair  of  nonces.  This  construction 
models  the  server  being  prepared  to  engage  in  any  run  it  is 
requested  to  participate  in.  The  outer  indexed  interleaving 
box  models  the  condition  that  the  server  Server{j)  may  be 
engaged  simultaneously  in  many  protocol  runs,  each  with  a 
different  session  key,  including  some  bogus  runs  initiated  by 
the  intruder  Intruder {X). 

3.6  User  Structure 

The  model  is  completed  by  boxes  for  each  of  the  users. 
In  order  to  model  a  protocol  of  this  kind,  each  user  should 
be  able  to  play  either  role,  initiator  or  responder.  Figure 
6  shows  the  high-level  structure  of  a  user,  either  Alice  or 
Bob.  Each  user  is  composed  of  two  boxes,  one  for  the  user’s 
role  as  a  protocol  run  initiator  and  one  for  its  role  as  a 
responder.  The  role  modeling  boxes  are  composed  into  a 
single  user,  via  an  interleaving  box,  to  model  the  possibility 
of  that  user  being  engaged  simultaneously  in  several  protocol 
runs  in  either  role. 

Within  the  high-level  structure  of  a  user,  the  model  de¬ 
fines  the  initiator  and  responder  runs  over  all  possible  com¬ 
binations  of  principal  names,  session  keys,  and  nonces.  We 
examine  the  structure  of  the  responder  role  first,  because  it 
is  simpler.  The  lower  part  of  Figure  7  shows  the  box  for  the 
responder  role,  for  user  Alice.  The  lower  part  of  Figure  7 
does  not  introduce  any  new  GSPML  notation.  The  struc¬ 
ture  of  the  Responder(a)  box  is  similar  to  the  structure  of 
the  server  box  Server(j)  shown  in  Figure  5:  an  outer  inter¬ 
leaving  box  that  allows  a  responder  to  be  engaged  simulta¬ 
neously  in  several  runs  of  the  protocol,  each  distinguished 
by  the  responder’s  choice  of  nonce  Ua  in  the  second  step  of 
the  protocol.  One  implication  of  this  construction  is  that 
a  Responder  may  be  engaged  in  several  protocol  runs,  each 
run  having  identical  values  of  a,b,nb,  and  kab-  While  a 
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Figure  7:  Yahalom:  The  Single  User  Alice 


properly  implemented  protocol  will  not  do  this  for  a  legiti¬ 
mate  run,  an  intruder  might  try  it.  A  good  protocol  model 
will  be  able  to  reflect  this  and  support  the  investigation  of 
its  consequences.  The  indexed  external  choice  box  that  de¬ 
fines  Responder{a,  Ua)  within  the  interleaving  box  gives  us  a 
choice  of  every  possible  responder  process,  over  session  keys 
kab,  initiator  nonces  Ub^ ,  and  initiator  names  b.  There  is  no 
recursion  here;  once  the  names,  nonces,  and  session  keys  are 
fixed,  the  responder  runs  until  a  session  is  established,  as 
shown  by  the  process  name  Session{b,a,kba,na,nb)  in  the 
process  region  of  the  innermost  box. 

The  most  complex  component  of  our  complete  model  is 
the  initiator  role.  It  introduces  one  new  GSPML  construct, 
the  menu  choice  box.  Menu  choice  boxes  offer  a  choice  of 
first  events,  from  a  single  box,  rather  than  a  choice  of  boxes. 
The  menu  choice  box  of  Figure  7  is  contained  inside  indexed 
interleaving  box  Initiator  (a).  Menu  choice  is  denoted  by  the 
double  diamond  event  choice  symbol.  Above  the  event  choice 
symbol  there  is  a  single  event  name  envlb  :  Users  that 
denotes  a  choice  of  event  b  of  type  U sers,  received  from  the 
environment  env  of  the  box  .  Other  than  this  one  new  box, 
the  rest  of  Figure  7  uses  notation  already  explained.  Notice 
this  initial  event  is  not  connected  via  a  synchronization  line. 

The  added  complexity  in  the  initiator  arises  because  of 
the  need  to  model  an  initiator’s  ability  to  start  legitimate 
protocol  runs  entirely  as  a  consequence  of  its  own  decision. 
That  is,  the  intruder  Intruder (X)  should  not  be  able  to  force 
any  user  to  start  a  legitimate  protocol  run.  Otherwise,  the 
intruder  either  has  mind  control  powers  over  the  human  user 

^When  Alice  is  responder,  the  subscripts  are  reversed. 


or  has  obtained  control  of  the  user’s  host.  An  intruder  in 
either  of  these  situations  has  no  reason  to  try  to  break  this 
session  key  establishment  protocol.  So  the  initiator  has  to 
use  menu  choice  to  allow  its  environment  (i.e.  the  human 
user)  to  chose  the  responder. 

The  outer  structure  of  the  Initiator  box  in  Figure  7  is 
similar  to  the  responder’s  structure.  An  interleaving  box 
models  concurrent  runs  of  the  protocol  using  different  ini¬ 
tiator  nonces  Ua  ■  Within  the  interleaving  of  runs  defined  by 
possible  nonces  the  menu  choice  box  models  the  initiator’s 
choice  of  responder. 

Within  the  process  region  of  this  menu  choice  box  that 
selects  a  user  b  we  find  a  simple  sequential  box  for  each  pos¬ 
sible  choice  of  user  received  from  channel  env.  This  simple 
sequential  box  transmits  the  applicable  nonce  to  the  chosen 
user’s  responder.  The  process  region  of  this  simple  sequen¬ 
tial  box  uses  an  external  choice  box  to  select  the  box  that 
finishes  the  initiator’s  part  of  a  single  run,  given  the  nonce 
chosen  and  returned  by  the  responder  b.  Once  the  respon¬ 
der  has  chosen  a  nonce  the  rest  of  the  initiator  becomes 
a  single  run  via  a  sequential  box,  just  like  the  server  and 
responder  boxes  seen  earlier. 

3.7  Modeling  a  Non-Cryptographic  Protocol 

We  can  demonstrate  the  versatility  of  GSPML  by  model¬ 
ing  a  non-cryptographic  security  protocol,  and  use  this  sec¬ 
ond  example  as  an  opportunity  to  introduce  further  GSPML 
notation.  In  contrast  to  the  preceding  example  of  the  Ya- 
halom  protocol,  information  flow  security  protocols  do  not 
involve  cryptography.  Intuitively,  an  information  flow  secu¬ 
rity  protocol  involves  a  resource  that  is  shared  between  two 
environments  High  and  Low.  The  resource  is  supposed  to 
provide  shared  service  to  both  High  and  Low  but  prevent 
information  from  flowing  from  High  to  Low. 

The  problem  is  not  as  easy  as  it  looks  and  is  still  a  research 
topic.  One  of  the  most  difficult  parts  of  the  problem  is  defin¬ 
ing  absence  of  information  flow.  There  are  simple  definitions 
of  an  information-flow-secure  resource  shared  between  High 
and  Low  that  are  clearly  effective  but  inhibit  or  preclude 
functionality.  For  example,  if  the  allowable  security  proto¬ 
col  provides  no  services  to  the  High  environment,  then  the 
shared  resource  in  question  will  be  information  flow  secure. 
The  difficulty  is  getting  a  less  restrictive  definition  of  an  al¬ 
lowable  protocol  that  still  has  acceptable  information  flow 
properties.  GSPML  can  both  define  allowable  information 
flow  and  model  the  protocols. 

We  now  define  information  flow  security,  for  a  simple  ser¬ 
vice  protocol.  The  definition  of  information  flow  security  is 
taken  from  Ryan  and  Schneider  [34].  The  definition  is  not 
the  best  proposed  by  Ryan  and  Schneider  [34]  but  is  chosen 
because  it  can  show  GSPML  notation  we  have  not  seen  yet. 
Readers  interested  in  information  flow  security  can  refer  to 
McLean  ]26]. 

The  most  significant  difference  in  this  example  is  that  we 
are  now  modeling  a  relation  between  two  GSPML  models. 
In  our  case,  the  relation  is  equivalence'^  between  the  un¬ 
named  box  of  Figure  8(a)  and  the  unnamed  box  on  of  Figure 
8(b). 

The  new  feature  of  GSPML  used  in  this  example  is  that 
both  parts  of  Figure  8  use  a  hiding  box.  A  hiding  box  makes 

^For  definitions  of  information  flow  security,  the  specific 
kind  of  equivalence  is  significant,  but  a  discussion  of  that 
would  detract  from  our  main  point. 
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Figure  8:  Modeling  an  Information-Flow-Secnrity 
Protocol 


events  inside  it  invisible  to  the  environment  of  the  hiding 
box;  inside  the  hiding  box  the  hidden  events  are  still  visible. 
A  hiding  box  is  distinguished  by  its  strikethrough  symbols; 
the  strikethrough  symbols  indicate  the  events  that  are  to 
be  hidden  in  the  enclosed  box.  Outside  the  hiding  boxes  of 
Figure  8  events  atom  and  blow  are  visible  but  events  auigh 
and  bhigh  are  invisible.  Inside  the  hiding  box,  all  four  events 
are  visible  when  they  take  place. 

The  box  construction  on  the  right  side  of  Figure  8  is  using 
synchronization  with  the  constant  box  STOPh  to  block  H 
(i.e.  High)  events  in  the  box  Protocol.  The  constant  box 
STOP  is  a  process  box  that  never  performs  events.  It  may 
be  considered  to  have  an  interface  with  visible  events,  but 
it  never  performs  them.  Thus  STOP  generates  only  one 
trace:  ().  STOP  does  not  represent  normal  termination  but 
deadlock  or  a  blocked  process.  When  boxes  are  synchronized 
via  a  parallel  box  but  the  combination  reaches  a  point  in  its 
execution  where  one  of  them  is  not  prepared  to  synchronize 
then  the  combination  blocks.  In  this  case,  since  box  STOPh 
has  precisely  all  the  H  events  of  box  Protocol,  only  L  events 
happen  in  the  combination. 

Figure  8  uses  the  process  box  Protocol  to  define  the  ser¬ 
vice  itself  and  the  two  models  containing  copies  of  Protocol 
to  define  information  flow  security  for  the  service.  Essen¬ 
tially,  the  GSPML  of  Figure  8  defines  information  flow  se¬ 
curity  for  Protocol  as  the  condition  that  any  behavior  of 
Protocol  with  the  H  events  hidden  (i.e..  Figure  8(a))  is  the 
same  as  any  behavior  of  Protocol,  with  its  H  events  blocked 
and  then  hidden  (i.e.,  Figure  8(b)).  The  implications  of  this 
definition  may  be  understood  by  considering  that  an  arbi¬ 
trary  intruder  box  may  be  inserted  as  synchronized  with  the 
Protocol  box  inside  each  model  of  Figure  8;  thus  there  is  po¬ 
tential  for  different  behavior  to  be  visible  between  the  two 
parts  of  Figure  8.  For  example,  an  adversary  added  to  Fig¬ 
ure  8(a)  can  use  the  external  choice  semantics  of  Protocol  to 
selectively  choose  the  second  inner  box  of  Protocol  (the  one 
that  does  bhigh)  but  then  only  request  event  auigh,  resulting 
in  a  failure  (i.e.  a  covert  channel) .  A  similar  adversary  could 


be  added  to  Figure  8(b)  but  would  not  be  able  to  block  the 
(already  blocked)  high  events. 

Adding  specific  details  to  the  protocol  (i.e.  the  Protocol 
box)  is  a  key  step  in  modeling  information  flow  security.  The 
example  uses  two  simple  events  a  and  b  while  a  more  realistic 
example  might  use  events  like  create- channel,  start-channel, 
stop-channel,  dear-channel  and  delete- channel  for  a  mul¬ 
tilevel  boundary  controller.  Some  specifications  of  Protocol 
will  define  sets  of  traces  (and  failures)  that  result  in  equality 
and  others,  sometimes  surprisingly,  will  not.  The  process  of 
designing  a  suitable  information  flow  security  protocol  in¬ 
volves  trade  offs  between  the  specification  of  Protocol,  the 
protocol  itself,  and  the  pair  of  enclosing  security  definition 
boxes. 

Figure  8  also  demonstrates  the  compositional  nature  of 
GSPML  models.  If  the  service  defined  by  the  box  named 
Protocol  is  to  have  another  security  property  besides  infor¬ 
mation  flow  security,  then  the  box  named  Protocol  can  be 
removed  unchanged  from  the  hiding  and  blocking  equiva¬ 
lence  and  placed  in  a  model  for  that  property. 

4.  RELATED  WORK 

After  looking  at  two  examples,  it  may  be  helpful  to  con¬ 
sider  related  work  and  analyze  it  according  to  our  criteria. 
With  our  criteria;  event-based,  composable,  comprehensive, 
concise,  well-defined,  we  can  assess  the  suitability  of  the 
various  MDA/UML  models  for  security  protocol  design  and 
analysis.  We  can  also  investigate  the  usefulness  of  other 
modeling  approaches  that  are  not  part  of  the  MDA  suite. 

4.1  UML  Candidates 

To  model  security  protocols  in  UML,  we  must  use  one  or 
more  of  the  available  modeling  mechanisms:  actions,  activ¬ 
ities,  interactions,  state  machines,  or  use  cases.  Use  case 
models  are  high-level  requirements  tools  and  use  the  other 
visual  modeling  techniques  to  describe  behavior,  so  they  are 
not  candidates  for  modeling  any  but  the  most  rudimentary 
concepts  of  security  protocols.  UML  Actions  include  con¬ 
structs  such  as  BroadcastSignal,  ReadVariable,  and  WriteLink; 
they  correspond  to  individual  events,  methods,  messages,  or 
calls.  Thus,  they  are  also  not  suited  to  modeling  complete 
security  protocols. 

UML  Activities  organize  UML  Actions  into  structures  that 
resemble  Petri  nets.  UML  Activities  employ  control-  and 
data-flow  relationships  in  their  Petri-net-like  structures,  which 
is  less  desirable  when  the  issue  is  protocols  and  we  wish  to 
avoid  details  about  internal  computations. 

UML  Interactions  are  similar  to  ITU  Standard  Z.120  Mes¬ 
sage  Sequence  Charts,  or  the  older  UML  1.x  Sequence  Di¬ 
agrams:  a  collection  of  vertical  life-lines  with  message  flow 
between  the  lifelines  shown  horizontally.  Both  UML  Inter¬ 
actions  and  ITU  Message  Sequence  Charts  have  semantic 
problems.  Damm  and  Harel  have  provided  a  well-defined 
semantics  for  these  kinds  of  diagrams,  in  a  visual  model¬ 
ing  technique  called  Live  Sequence  Charts  [10] .  All  of  these 
“sequence-diagram”  modeling  paradigms  have  the  critical 
strength  of  being  event-based:  they  model  sequences  with¬ 
out  internal  computational  detail.  That  is,  they  model  be¬ 
havior  directly  in  terms  of  protocol  traces.  Unfortunately, 
they  all  have  limited  usefulness  in  modeling  security  pro¬ 
tocols  because  each  diagram  defines  only  a  subset  of  the 
traces  of  a  protocol.  The  nature  of  these  diagrams  is  that 
they  visually  enumerate  traces  and  lack  the  power  of  set 


theory  or  process  algebra  to  explicitly  define  all  possible 
traces  of  a  combination  of  principals.  For  example,  suppose 
we  use  the  BPA  (Basic  Process  Algebra)  process  algebra  of 
Bergstra  and  Klop  [1]  to  define  P  =  a- P,  the  process  P  that 
does  event  a  and  then  acts  like  process  P.  If  the  expression 
traces(P)  means  the  set  of  all  traces  of  process  P  and  the 
symbol  denotes  concatenation  of  traces  then  we  can  use 
set  theory  to  explicitly  define  all  of  the  traces  of  P  =  a  ■  P 
as 

{()}  U  {{a)^tr  I  tr  €  traces(P)} 

while  the  corresponding  “sequence-diagram”  enumeration 
approach  is  equivalent  to  the  symbolic  listing  of  each  possi¬ 
ble  trace 

(),(a),(a,a),... 

As  soon  as  there  is  a  modest  variation  in  the  pattern  of  the 
traces,  this  enumeration  approach  begins  to  break  down.  In 
contrast,  process  algebra  or  set  theory  provides  us  a  com¬ 
plete  definition  in  a  single  model  but  still  allows  us  to  unwind 
the  model  to  see  or  check  any  trace.  The  visual  modeling 
equivalent  of  set  theory  or  process  algebra  is  needed  to  solve 
this  problem. 

UML  State  Machines  would  appear  to  offer  some  promise. 
They  are  based  upon  (but  are  not  the  same  as)  the  object- 
oriented  version  [17]  of  Harel’s  elegant  statechart  [16]  vi¬ 
sual  formalism.  Since  statecharts  are  a  well-defined  visual 
model,  UML  State  Machines  should  be  able  to  dehne  com¬ 
pletely  any  security  protocol,  with  a  single  model.  Unfor¬ 
tunately,  UML  State  Machines  have  some  problems:  1)  re¬ 
ceived  events  are  modeled  by  a  different  mechanism  that 
sent  events,  2)  the  semantics  are  run-to-completion  which 
poses  problems  for  modeling  some  forms  of  recursion  (Ten- 
zer  and  Stevens  [40]  provide  good  examples  of  this),  and  3) 
some  of  the  events  are  not  atomic  [28] .  Some  of  these  prob¬ 
lems  are  avoided  by  the  concept  of  UML  Protocol  State  Ma¬ 
chines.  UML  Protocol  State  Machines  are  like  UML  State 
Machines  without  UML  Activities.  That  is,  a  UML  Protocol 
State  Machine  only  has  triggers  associated  with  its  transi¬ 
tions  while  the  more  general  UML  State  Machine  also  has 
UML  Activities  associated  with  its  transitions.  The  effect 
of  this  is  that  a  UML  Protocol  State  Machine  can  describe 
one  side  of  an  interaction  between  two  security  principals: 
either  the  sequence  of  requests  a  principal  can  make  or  the 
sequence  of  responses  that  that  a  principal  can  provide.  This 
is  sufficient  for  constraining  interfaces  but  not  for  modeling 
a  complete  security  protocol. 

From  these  circumstances  we  can  conclude  that  UML  is 
not  well-suited  to  modeling  security  protocols.  This  leads 
us  to  examine  other  visual  modeling  techniques  outside  of 
UML,  to  see  if  they  are  better  tools  for  modeling  security 
protocols. 

4.2  Existing  Visual  Models  Outside  of  UML 

We  have  already  mentioned  Live  Sequence  Charts  as  a 
well-defined  event-based  modeling  technique.  The  problem 
of  needing  more  than  one  diagram  to  define  all  of  a  proto¬ 
col  remains.  Another  possibility  is  a  visual  representation 
of  labeled  transition  systems.  A  labeled  transition  system 
or  LTS  is  a  triple  (F,  A,  — >)  where  F  is  a  set  of  configu¬ 
rations,  A  is  a  set  of  events,  and  ^  is  a  ternary  relation: 
^  C  F  X  A  X  F.  Intuitively,  the  relation  ^  represents  the 
transitions  from  one  conhguration  to  another;  (7,  a,  7')  £  — > 
is  usually  written  as  7  7'.  Labeled  transition  systems 


are  ideal  for  machine  representation  and  processing  of  event 
systems.  The  problem  with  labeled  transition  systems  as  a 
visual  modeling  paradigm  is  the  same  problem  that  lead  to 
the  development  of  statecharts:  “the  unmanageable,  expo¬ 
nentially  growing  multitude  of  states,  all  of  which  have  to  be 
arranged  in  a  ‘flat’  unstratified  fashion”  [16].  Labeled  transi¬ 
tion  systems  are  not  concise.  Current  LTS  work  is  turning  to 
algebraic  treatments  to  overcome  this  difficulty.  Petri  nets 
were  developed  by  Carl  Petri  [33]  for  formal  modeling  of  con¬ 
currency,  nondeterminism,  and  communication.  Petri  nets 
are  well-defined  and  have  a  large  body  of  literature.  They 
are  useful  for  a  wide  range  of  problems  including  workflow 
and  performance  modeling.  The  difficulty  with  using  them 
to  model  security  protocols  is  the  presence  of  computation 
details:  initial  markings,  places,  transitions,  and  data  flow. 
They  are  not  event-based.  Another  difficulty  is  that  Petri- 
net-based  models  are  not  naturally  composable  in  terms  of 
security  principals. 

Port  state  machines,  a  formalism  developed  by  Mend  [28] , 
have  removed  the  semantic  difficulties  associated  with  UML 
State  Machines,  while  retaining  the  semantic  clarity  of  state- 
charts.  Furthermore,  port  state  machines  also  address  mod¬ 
eling  details  needed  for  object-oriented  programming,  which 
the  original  statecharts  lack.  However,  because  of  this  and 
their  state-based  nature,  port  state  machines  have  too  much 
computational  detail  for  modeling  security  protocols.  They 
are  not  event-based. 

Harel’s  original  statecharts  are  a  good  candidate  for  mod¬ 
eling  security  protocols,  because  they  lack  the  extra  details 
needed  to  model  object-oriented  programming  issues.  They 
are  semantically  sound  and  can  define  an  entire  protocol 
with  a  single  diagram.  Statecharts  also  have  excellent  visual 
modeling  characteristics.  They  are  not  event-based  and  re¬ 
quire  consideration  of  states  and  transitions  as  well  as  the 
events  they  model.  We  would  prefer  a  more  directly  event- 
based  modeling  paradigm. 

Walters  has  designed  RDT  [42]  as  a  formal  visual  language 
based  on  activity  diagrams.  RDT  is  designed  foremost  for 
visual  clarity,  just  what  is  needed  for  visual  modeling  of 
security  protocols.  It  would  be  a  good  candidate  but  it  uses 
an  LTS  form  of  depicting  behavior,  so  it  is  not  event-based. 

Another  alternative  we  have  not  considered  up  to  now  is 
a  graphical  form  of  process  algebra.  Process  algebras  are 
event-based  but  avoid  the  explosive  complexity  of  labeled 
transition  systems  by  means  of  algebraic  operators.  Process 
algebras  view  processes  as  abstract  trace  generators  and  pro¬ 
vide  means  for  composing  processes  to  define  more  complex 
trace  generators. 

Cleaveland,  Du,  and  Smolka  developed  Graphieal  Caleu- 
lus  of  Communicating  Systems  (GCCS)  [8]  as  part  of  the 
Concurrency  Factory  tool  [9].  The  GCCS  visual  notation  is 
based  on  Milner’s  CCS  [31]  process  algebra  but  the  diagrams 
are  visual  depictions  of  labeled  transition  systems.  GCCS 
diagrams  have  the  same  visual  limitations  as  basic  labeled 
transition  systems:  they  are  not  concise. 

Cerone  developed  Visual  Process  Algebra  or  VPA  [6],  a 
modeling  technique  based  on  combinations  of  the  CCS,  CSP 
[21],  and  Circal  [30]  process  algebras.  The  VPA  approach 
models  processes  as  boxes  with  ports  to  indicate  communi¬ 
cation  and  thus  has  the  potential  to  be  event-based.  Un¬ 
fortunately,  VPA  uses  an  LTS  or  state-machine  approach 
within  each  box  to  model  the  behavior  of  the  correspond¬ 
ing  process.  For  security  protocol  modeling  we  would  really 
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Figure  9:  Resolving  Compositional  Ambiguity  in 
gCSP 


prefer  an  approach  that  avoids  labeled  transition  systems 
altogether. 

Gilmore  and  Gribaudo  [13]  extended  the  DrawNET  tool 
to  model  the  PEPA  [20]  stochastic  process  algebra.  The 
DrawNET  tool  is  oriented  towards  performance  modeling; 
the  graphical  representation  of  process  algebra  retains  the 
Petri  nets  of  the  underlying  tool,  so  the  DrawNET  repre¬ 
sentation  is  not  really  well-suited  to  modeling  security  pro¬ 
tocols. 

The  gCSP  (for  graphical  CSP)  tool,  developed  by  Hilderink, 
Jovanovic,  et  al.  [19,  22]  is  the  most  ambitious  graphical 
form  of  process  algebra  to  date.  Processes  are  denoted  as 
circles  in  gCSP.  Lines  connecting  the  processes  denote  com¬ 
position  via  the  various  operators  of  CSP.  A  surprising  omis¬ 
sion  is  the  graphical  modeling  of  events  and  their  ordering 
within  a  sequential  process.  That  is,  even  though  gCSP  can 
cleanly  show  sequential  processes  P  and  Q  in  parallel  P  \\  Q, 
it  cannot  show  the  events  that  make  up  sequential  process  P 
(or  Q).  This  is  not  a  difficulty  for  control  applications  that 
gCSP  has  been  applied  to,  but  it  is  critical  for  modeling 
security  protocols. 

From  a  security  protocol  modeling  perspective,  the  gCSP 
notation  is  interesting  because  it  presents  a  contrast  to  the 
graphical  modeling  paradigm  proposed  in  this  paper.  Pro¬ 
cess  algebras  are  strongly  compositional.  It  is  difficult  to 
present  complex  process  algebra  relationships  graphically. 
Figures  9  and  10  illustrate  this  difficulty  in  the  gCSP  nota¬ 
tion.  Figure  9  shows  the  process  algebra  fragment  P-,Q\\R 
which  is  an  ambiguous  term  specifying  the  sequential  (via 
the  ;  operator)  and  parallel  (via  the  [[  operator)  composition 
of  processes  P,  Q  and  R.  Figure  9  (a)  shows  how  this  am¬ 
biguity  can  be  drawn  in  gCSP.  Figure  9  (b)  shows  how  this 
ambiguity  can  be  resolved  by  drawing  cycles  to  add  arcs  for 
all  relationships.  This  is  problematic  in  complex  composi¬ 
tions  since  the  diagram  tends  to  become  a  fully  connected 
graph.  The  gCSP  notation  has  a  clever  solution  to  this, 
shown  in  Figure  9  (c),  where  a  smaller  circle  is  used  on 
one  side  to  denote  the  precedence.  The  notation  is  well- 
defined  and  capable  of  automatic  simplification.  However, 
in  complex  situations,  the  notation  becomes  difficult  to  read, 
as  shown  by  Figure  10.  However,  it  is  the  lack  of  explicit 
events  that  renders  gCSP  unsuitable  for  security  protocol 
modeling. 

4.3  Security  Protocol  Modeling  Tools 

Another  possibility  is  the  (visual)  modeling  provided  by 
security-protocol-specific  tools.  Most  of  the  these  tools  have 


Figure  10:  Complex  Composition  in  gCSP 


visual  modeling  components  and  it  is  possible  that  we  may 
find  a  satisfactory  (from  the  visnal  modeling  perspective) 
language  or  technique  there.  Considering  these  tools  will 
also  clarify  onr  emphasis  on  presentation  and  understand¬ 
ing  as  opposed  other  purposes  such  as  verification  or  anal¬ 
ysis.  Clearly  the  existing  tools  are  effective  for  those  other 
purposes. 

The  Security  Protocol  Engineering  and  Analysis  Resource 
(SPEAR)  tool  [36]  provides  multidimensional  protocol  anal¬ 
ysis.  Multidimensional  protocol  analysis  combines  several 
non- visual  modeling  approaches  in  order  to  get  a  more  com¬ 
plete  picture  of  the  security  of  a  cryptographic  security  pro¬ 
tocol.  The  SPEAR  tool  incorporates  multidimensional  pro¬ 
tocol  analysis  under  a  graphical  user  interface.  Unfortu¬ 
nately,  SPEAR  uses  message  sequence  charts  to  visually 
model  security  protocols.  Its  graphical  language  is  not  com¬ 
prehensive. 

The  Common  Authentication  Protocol  Specification  Lan¬ 
guage  (CAPSL)  and  MuCAPSL,  its  group  multicast  pro¬ 
tocol  version,  is  a  formal  language  for  specifying  crypto¬ 
graphic  security  protocols  [29] .  CAPSL  is  well-defined,  con¬ 
cise,  comprehensive,  and  compositional.  CAPSL  models  can 
be  translated  into  many  forms  and  several  cryptographic 
protocol  analysis  tools  have  CAPSL  support.  Unfortunately, 
there  is  no  visual  form  of  CAPSL  per  se. 

The  Convince  tool  is  a  pioneer  effort  in  visual  modeling  of 
cryptographic  security  protocols  [25].  Convince  uses  a  text- 
based  formal  language  based  on  BGNY  ]4]  logic.  Unfortu¬ 
nately,  the  characteristics  of  BGNY  do  not  carry  over  into 
the  visual  modeling  language,  which  is  essentially  a  version 
of  UML.  In  particular,  protocol  steps  are  modeled  visually 
using  message  sequence  charts. 

One  security  protocol  analysis  tool  that  does  use  a  dis¬ 
tinct  security-specific  visual  language  is  the  NRL  Protocol 
Analyzer  (NPA)  ]27].  NPA  has  its  own  text-based  language 
NPATRL  (pronounced  “N  Patrol” )  that  models  a  wide  range 
of  security  protocol  requirements.  NPATRL  is  an  event- 
based  language  for  expressing  trace  properties.  It  uses  fa¬ 
miliar  logic  operators  and  one  temporal  operator  to  define 
logical  properties  of  events  or  traces.  The  NPA  tool  has 
a  corresponding  tree-structured  language  for  visual  mod¬ 
eling  of  NPATRL  specifications  [7].  The  visual  language 
is  event-based,  concise,  and  well-defined.  Our  motive  for 
looking  further  is  that  the  visual  NPATRL  language  is  a 
trace-property-language  while  we  are  looking  for  a  protocol- 
definition  language.  That  is,  the  visual  NPATRL  language 
does  not  define  the  traces  of  a  particular  protocol,  but  the 
properties  (i.e.  requirements)  of  a  good  protocol.  We  are 
looking  for  a  language  that  can  define  protocols  as  they  op¬ 
erate,  good  or  bad. 


4.4  UML-Based  Security  Modeling 

Some  work  has  been  done  on  security  modeling  with  UML. 
Epstein  and  Sandhu  [11]  show  how  UML  can  be  used  to 
model  RBAC  policies.  Jiirjens  [23]  has  proposed  UMLsec 
as  a  means  of  annotating  UML  with  sterotypes  and  tagged 
values,  to  specify  security  requirements.  Basin,  Doser,  and 
Lodderstedt  [2]  have  extended  UML,  via  sterotypes,  to  Se- 
cureUML.  The  SecureUML  language  can  be  used  to  specify 
access  control  requirements  on  UML  Glass  Diagrams  and 
UML  Statemachines.  None  of  this  work  covers  security  pro¬ 
tocol  modeling.  Nevertheless,  it  supports  our  observation 
that  bare  UML  does  not  treat  security  issues  adequately. 

5.  CONCLUSIONS 

Our  first  conclusion  is  that  visual  modeling  does  not  mag¬ 
ically  make  complex  security  issues  simple.  The  two  exam¬ 
ples  were  chosen  because  they  are  as  complex  and  realistic 
as  can  be  presented  in  a  brief  paper.  The  GSPML  depiction 
cannot  remove  inherent  complexity  from  a  security  proto¬ 
col,  but  it  can  present  security  protocols  in  a  laconic  form. 
The  fact  that  GSPML  generates  correspondingly  complex 
models  is  a  good  thing:  since  simplicity  and  minimality  are 
explicit  design  goals  of  security,  a  tool  that  makes  adding 
unneeded  complexity  an  unpleasant  experience  is  a  design 
aid. 

Some  complex  concepts  can  be  understood  more  quickly 
by  visual  means.  Visual  descriptions  are  sometimes  prefer¬ 
able  to  text-based  notation.  GSPML  provides  those  benefits 
for  security  protocols. 

Our  second  conclusion  is  that  GSPML  is  a  modeling  lan¬ 
guage  that  meets  the  security  protocol  modeling  criteria: 
event-based,  compositional,  comprehensive,  laconic,  lucid, 
sound,  complete,  and  well-defined.  There  is  no  other  vi¬ 
sual  modeling  technique  that  satisfies  all  of  these  criteria. 
The  current  Model  Driven  Architecture  does  not  provide 
security-specific  modeling  facilities  and  its  general  modeling 
facilities  fail  to  satisfy  one  or  more  of  the  security  protocol 
modeling  criteria.  There  are  well-defined  visual  formalisms 
outside  of  the  UML  that  could  be  used  to  model  security 
protocols:  labeled  transition  systems,  Harel’s  original  stat- 
echarts,  and  Petri  nets.  However,  each  of  these  three  is  also 
lacking  according  to  at  least  one  criterion. 

A  comment  on  our  second  conclusion  is  that  all  of  the 
modeling  approaches  considered  in  Sections  4.1  and  4.2  are 
useful  and  in  some  cases  superior  to  GSPML,  for  applica¬ 
tions  other  than  security  protocol  modeling.  For  instance,  a 
lack  of  states  and  other  internal  computational  details  makes 
GSPML  less  suitable  for  modeling  object-oriented  imple¬ 
mentations.  GSPML  is  for  modeling  and  defining  proto¬ 
cols  visually.  Other  than  through  some  visual  form  of  the 
rank  function  approach  [37],  GSPML  is  probably  not  suited 
to  verification  or  analysis  of  protocols  but  should  be  used 
as  a  front-end  for  a  protocol  analysis  tool  as  considered  in 
Section  4.3 

Our  third  conclusion  is  that,  from  a  visual  modeling  point 
of  view,  the  idea  of  a  security  protocol  should  be  generalized 
to  any  form  of  interaction  between  security  principals.  The 
proposed  notation  should  be  security  or  protocol  specific, 
rather  than  specialized  to  only  cryptographic  protocols. 

Our  final  conclusion  regards  the  application  of  GSPML. 
Security  protocol  design  and  modeling  is  usually  consid¬ 
ered  a  specialist  responsibility,  even  by  security  specialists. 


Thus  security  protocols  are  outside  the  expertise  of  a  gen¬ 
eral  software  developer.  Why  then  would  we  need  a  mod¬ 
eling  language  just  for  security  protocols?  There  are  three 
reasons:  1)  security  specialists  benefit  from  visual  modeling, 
as  demonstrated  by  the  visual  components  of  the  tools  de¬ 
scribed  in  Section  4.3  above,  2)  a  visual  presentation  may 
be  more  useful  to  software  developers  who  have  to  imple¬ 
ment  the  security  protocol  and  thus  serve  as  a  bridge  from 
security  specialist  to  other  developers,  3)  many  security  pro¬ 
tocols  fail  because  they  are  used  in  new  or  different  environ¬ 
ments;  GSPML  models  may  reveal  the  impact  of  the  new 
environment  more  clearly  than  a  text-based  model.  This 
result  is  supported  by  the  fact  that  (non-security-protocol) 
security  specialists  at  the  New  Security  Paradigms  Work¬ 
shop  were  able  to  identify  protocol  flaws  in  a  few  minutes, 
using  GSPML  after  less  than  a  30  minute  initial  exposure 
to  the  language. 

Given  that  fact  that  good  well-defined  visual  languages 
are  syntactic  sugar  for  some  text-based  langauge  we  chose 
to  use  an  existing  semantics  rather  than  define  a  new  one. 
The  essential  GSPML  diagramming  approach  is  compatible 
with  several  forms  of  process  algebra.  That  is,  the  differ¬ 
ences  in  the  various  process  algebras  are  not  great  enough  to 
require  substantially  different  diagrams.  In  our  experience, 
we  have  used  GSPML  to  visually  depict  security  protocol 
models  of  both  classical  GSP  and  PEPA  stochastic  process 
algebra  semantics.  It  should  be  possible  to  use  GSPML-like 
diagrams  for  CGS  [31]  or  AGP  [3,  1]  semantics. 

Our  future  work  on  GSPML  will  include  further  prototyp¬ 
ing  and  application,  to  validate  the  syntax,  semantics,  and 
pragmatics  (e.g.  laconicity).  We  will  also  strive  to  improve 
the  balance  [41]  between  security  protocol  complexity  and 
the  complexity  of  visual  models  drawn  in  GSPML. 
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